Harness Engineering 工程化落地指南
Harness Engineering 工程化落地指南
来源: 腾讯云开发者 - 白家杰 原文: https://mp.weixin.qq.com/s/77dyufF3MP8stHPS0BApNw
核心观点
Harness Engineering 不是一个工具或某条提示词技巧，而是一整套让 AI 在工程里稳定产出正确结果的工程系统。三个关键词：稳定（换需求换人仍能工作）、产出（覆盖需求→方案→验证→交付全流程）、正确结果（有办法判断做得对不对）。
本文从 SPEC 出发，逐步引入 Rule（Harness Engineering）、Skill、Sub Agent、Workflow（Harness Engineering）、Scripts（Harness Engineering）、MCP（协议） 六大核心概念，最终构建七 Agent 结构化调度架构。
第一章：六大核心概念
| 概念 | 回答什么问题 | 角色定位 |
|---|---|---|
| Rule（Harness Engineering） | 什么事绝对不能乱来 | 基础规矩、红线、底线 |
| Skill | 这件事具体应该怎么做 | 固定动作的标准操作手册 |
| Sub Agent | 复杂任务由谁分工处理 | 不同阶段的专业角色 |
| Workflow（Harness Engineering） | 这些角色按什么顺序接力 | 前进、暂停、打回、重跑规则 |
| Scripts（Harness Engineering） | 最后谁来判断到底做没做好 | 统一门禁和事后验证 |
| MCP（协议） | AI 怎么安全接上外部工程系统 | 外接能力与工具链 |
Rule — 软约束
给 AI 写的"工程规矩"，本质是带新人时先告诉他的基础原则。核心作用不是帮 AI"变聪明"，而是帮 AI 少犯低级错误。
重要前提：Rule 只是软约束，不是硬门禁。AI 可能忘了某条 Rule、觉得某条 Rule 与需求"无关"、知道但偷懒没做还给自己找理由。
典型示例：
改完代码以后，不能只说"我改好了"。必须去编译 → 必须去跑测试 → 必须去做事后验证。三步不全过，这次开发就不算完成。
Rule 一上去，最粗糙的问题会立刻少很多（"我改的是文档不用编译""只是小改不用跑测试"都会被阻止），但 Rule 有天花板：AI 在复杂任务下会"局部遗忘"（上下文重时被稀释），还会绕过 Rule 给自己找理由。
Rule 不是没用，而是 Rule 只能做"原则约束"，不能做"流程执行"。
Skill — 标准操作手册
告诉 AI 某些事情不要临场发挥，严格按固定步骤执行。适合做成 Skill 的特征：执行步骤固定、每次都要做、做错一次代价高、不值得让 AI 重新思考。
Rule vs Skill 的分工：
- Rule 告诉 AI "这件事必须做"
- Skill 告诉 AI "这件事具体应该怎么做"
Skill 的好处：Rule 变轻（只保留红线）、AI 执行稳定性变高（调用而非理解）、维护成本更低（改 Skill 本身，不需全项目搜索 Rule）。
Sub Agent — 多角色分工
单 Agent 的典型问题：自己给自己做需求解释（缺乏外部校验）、自己给自己方案打分（缺乏客观评估）、自己写代码自己说没问题（角色冲突）、倾向于推进任务而非承认问题（缺乏停止机制）。
解决方案：把不同阶段拆成不同 Agent，每个只负责自己那一段，把产出写进文档，交给下一个 Agent。
Workflow — 接力赛规则
不是"写了几个 Agent"那么简单，而是规定：当前任务处于哪个阶段、这个阶段的产出是什么、谁可以接下一棒、下一棒接手前必须看到什么文档、哪些问题一旦出现流程必须打回、打回以后回到谁那里从哪一棒重新开始。
三层架构：给人看（链路怎么走）、给系统看（阶段和迁移边固定下来）、给角色看（接棒该读什么、交棒该写什么）。
配套纪律：每一棒只给当前该看的那一份材料，避免上下文太长导致重点散掉。
Scripts — 硬门禁
真正成熟的 Harness，最后一定会越来越依赖脚本，而不是越来越依赖提示词。
典型总门禁脚本检查项：
| 静态规范问题 | 基础交付门槛 | 工程一致性 |
|---|---|---|
| XAML 里有没有中文 | 编译必须成功 | 规则文件是否完成多格式同步 |
| 有没有 Emoji | 测试必须全部通过 | .cs 文件是否都进了 .csproj |
| 有没有用 C# 8 以上语法 | 测试数量不能异常减少 | |
有没有直接写 MessageBox.Show | ||
| 有没有硬编码 UI 文案 |
MCP — 外部系统接口
把「仓库之外的能力」接进 AI 工作链路的标准化方式。典型动作：调用 CI 平台发起构建、读取构建日志和结果、调用签名服务、上传制品到制品库、调用发布系统做灰度/提审/发布、回写发布状态和版本号。
定位：MCP 是把 AI 接进更大工程系统的标准插座，不是 Harness 的主体。
第二章：从 SPEC 开始
很多人一听到 Harness，就想先写 Rule、先拆 Agent、先上脚本。但如果连"这个工程到底想怎么开发、最终想交付什么"都没说清楚，后面所有约束都会变成无源之水。
SPEC 必须明确的问题：这个版本到底要解决什么问题（核心目标）、哪些是核心目标哪些是顺手优化（优先级）、改动会影响哪些模块（边界）、哪些行为必须保持兼容（兼容性要求）、最终什么样才算做完（验收标准）。
质量要求：最终的 SPEC 必须没有任何不确定的词语，例如：建议、可以、推荐、可选等字样。
局限性：仅有 SPEC 只能解决"知道做什么"的问题，解决不了"如何稳定地做到位"。AI 会按自己理解跳过"没那么重要"的细节、做完后说"都完成了"但实际漏了、以前犯过的错下次又犯一遍。
第三章：三种技术路线对比
| 路线 | 最吸引人的地方 | 真正的问题 | 结果 |
|---|---|---|---|
| 继续强化单 Agent | 成本最低、改造最少 | 角色冲突越来越严重，长链路任务容易失稳 | 早期有效，不能成为最终形态 |
| 去中心化协作 | 灵活、像 AI 团队自由讨论 | 路径不稳定、责任边界不清、难长期维护 | 被明确放弃 |
| 结构化调度 | 流程清晰、文档化强、可审计 | 前期设计成本更高、产物更多 | 最终选择 |
真正贵的不是 token，真正贵的是失控。
结构化调度的两种做法：
- 做法 A：固定角色、固定流程（被选择） — 先定义有哪些 Agent、每个干什么、什么阶段找谁。工作流本身并不完全开放，没必要为理论灵活性牺牲稳定性
- 做法 B：动态生成 Agent — PM 和经理固定，具体 Agent 动态"招聘"。角色边界更漂、维护成本更高
第四章：七个 Agent 架构
| Agent | 职责 | 解决的问题 |
|---|---|---|
| PM | 路由、交接、回退、进度管理 | 链怎么有序串起来 |
| 需求分析 | 把模糊诉求变成清晰需求 | 想做什么 |
| 方案设计 | 把需求变成技术方案 | 打算怎么做 |
| 闸门总控 | 开发前最后的可行性和风险把关 | 现在能不能做 |
| 开发实现 | 真正落地代码 | 动手做 |
| 测试验证 | 验证开发产物是否符合要求 | 验收质量 |
| 发布验收 | 验收发布结果和最终交付 | 收单 |
闸门总控（Gatekeeper） 的特殊价值：方案设计完成后是否真的可以开始开发？有没有遗漏的边界条件？有没有未识别的风险？
第五章：三个演进阶段
| 阶段 | 形态 | 问题 |
|---|---|---|
| 阶段一 | 单 Agent 自由发挥 | 角色冲突、方案自评、缺乏停止机制 |
| 阶段二 | 引入 Rule 和 Skill | Rule 只能做原则约束，AI 会忽略或绕过 |
| 阶段三 | 结构化 Multi-Agent | 流程清晰、可审计、可演进，但前期设计成本高 |
核心结论
- Harness Engineering = 稳定产出正确结果的工程系统
- 六大核心概念：Rule、Skill、Sub Agent、Workflow、Scripts、MCP
- Rule 做原则约束，Skill 做流程执行，Scripts 做硬门禁 — 三者互补
- 结构化多 Agent > 单 Agent > 去中心化协作
- 真正贵的不是 token，真正贵的是失控
- 成熟的 Harness 越来越依赖脚本，而非提示词
关键引用
"Harness Engineering 是一整套让 AI 在工程里稳定产出正确结果的工程系统。"
"Rule 不是没用，而是 Rule 只能做'原则约束'，不能做'流程执行'。"
"真正贵的不是 token，真正贵的是失控。"
"真正成熟的 Harness，最后一定会越来越依赖脚本，而不是越来越依赖提示词。"
关联页面
- Harness Engineering — 核心概念
- Agent — Agent 基础定义
- Multi-Agent — 多 Agent 架构
- Skill — 标准操作手册
- Rule（Harness Engineering） — 软约束
- Workflow（Harness Engineering） — 接力赛规则
- Scripts（Harness Engineering） — 硬门禁
- Sub Agent — 多角色分工
- SPEC — 规格设计文档
- MCP（协议） — 外部系统接口
- Context Engineering — 上下文工程
- Prompt Engineering — 提示词工程